Default to dual stack if both A/AAAA records are available. #1927
Conversation
Test IPv6 by default if only AAAA records are discovered via DNS rather than failing. Allow IPv6-only testing via -only6 flag Allow IPv4-only testing via -only4 flag
|
Thanks. Basically I am not opposed to show "the other IP protocol'. via default. But as said it's not that easy. We cannot blame on users who lack IPv6 connectivity and show them a warning like this:
I tested this only on Linux so far.. BSD and WSL might be different. It shows the warning on Atm I lack time for this. So if you or anybody else can't give a hand it needs to wait. |
|
Agreed that the error message could be more informative, although "couldn't connect" is technically accurate. Keeping users informed is actually the whole point of this pull request, as ignoring IPv6 totally by default can leave users unaware that it's present on the target or that the system they're scanning from is unable to connect to it. On balance i feel it's better to display an error so the user is aware and can choose how they want to proceed. An inability to connect to a given target extends further than a lack of IPv6 on the source system. A similar error will occur if any of the targets are unreachable for whatever reason (eg they're down, or blocking you etc) but it's difficult to determine why exactly they are unreachable, hence the generic error and letting users check their own connectivity. I've actually seen pentest reports of dual stack sites where they assign ssl findings to the ipv4 address, but nothing to the ipv6 addresses (ie they probably didnt check them at all), since pentest reports are generally report-by-exception such reports lead the customer to draw the false conclusion that the ipv6 address has an optimal ssl configuration. The same error also occurs when users are on an IPv6-only or NAT64 network, but results in total failure rather than partial results unless HAS_IPv6 is true:
There are also other considerations on DNS64/NAT64 networks, since the DNS server will create AAAA records pointing through the NAT64 prefix when the target address does not have any of its own, but will pass through real AAAA records unmodified. You can still test all addresses in such a setup, but you need to be aware of your own NAT64 prefix and calculate the addresses yourself. Several major mobile operators are using NAT64 these days. The pre flight check is a good plan generally, i would propose going through each discovered address and attempting to connect to it once on the specified port. If any fail, display a prominent warning to the user suggesting they verify their network connectivity and give them an option to proceed with partial checks (if any of the addresses are reachable) or abort. I will look into how that could be implemented. Something else to be aware of however, some IPS systems will actually flag the repeated connections without subsequent valid HTTP requests as malicious and block you in the middle of a scan. In these instances the pre flight checks would go through ok but the scan would stall part way through. |
|
Detecting the presence of and the prefix in use by DNS64/NAT64 should be done by querying I also believe it is important to tell users of IPv4-only hosts that they can only partially test dual-stacked sites. Over 1/3rd of users worldwide have IPv6 connectivity, in Germany over 50%, and all of the German mobile networks support IPv6 by now, with Telekom already going IPv6-only by default. The problem from this is: let's assume a dual-stacked site. SSL is fine on IPv4, but broken on IPv6. If a person were testing from IPv4-only, it would see in the results that "everything is perfect". However, ~50% of users from Germany trying to access the site would do so over IPv6, and consequently would encounter problems. The person who ran the test should thus be made aware of the fact that IPv6-configuration of the dual-stacked site was not tested, and not falsely made believe that everything is fine and that it must be some undefined problem on the other users' end, while the actual problem is just a badly configured site on IPv6. |
|
ok, thanks. Wonder whether Microsoft-DNS-Clients are compliant. (see problems here with |
Patch to test IPv6 by default if the target host has AAAA records available via DNS.
IPv4 will still be tested by default if the target host has A records available via DNS.
If a host is dual stack and has both A/AAAA records and the "one" option has not been specified, both protocols and all addresses will be tested by default.
Add options -only4 and -only6 to force single-stack testing.
Default behaviour was to detect multiple IP addresses from a single FQDN and display all of them, but only test IPv4 addresses by default and ignore the IPv6. This patch changes the behaviour to test ALL addresses by default unless the user explicitly chooses otherwise.
Rationale:
If a user specifies a hostname they probably want to test all the addresses it resolves to in order to be thorough and identify any configuration anomalies, if they only wanted to test a subset of the addresses they would likely use the "one" option to just test one of them.
Qualys/SSLLabs SSLTest by default tests all addresses, and will report any errors encountered.
Any modern operating system will favour IPv6 when available, and only fall back to IPv4 if IPv6 is not available for whatever reason.
Ignoring the IPv6 addresses by default results in incomplete test results. SSL configuration may differ on IPv6. Because no errors are displayed, users may overlook this and assume the results given are complete.
If the system running ssltest.sh is unable to reach the IPv6 addresses, it will display errors (usually network unreachable) when trying to connect. This alerts the user to the fact that there is a problem with their ability to properly test the selected target, allowing them to investigate and either be aware of the limitations or correct them.
The same errors would occur if some of the targets are down, or if the user runs ssltest from an IPv6-only host against an IPv4 target etc.
A similar error will occur if the user has an old version of OpenSSL which is unable to support IPv6. As above, it is better that the user is made aware of the limitation so they can make an informed decision on how to proceed.
Before:
A user testing dual stack targets is performing incomplete scans and may not be aware they are doing so. While this is documented, users often don't read the documentation and are likely to blindly trust the output without thoroughly inspecting it, especially when this behaviour is different to other similar tools.
After:
A user with an IPv4-only host testing dual stack targets will see connection errors in the default state related to their own lack of IPv6 connectivity. This will make them aware that they are unable to perform thorough tests of the target, and have the choice to either proceed with incomplete testing using the -only4 option or perform testing from somewhere which is able to reach all of the targets.
The same results would be returned, but the user would be alerted to the fact that the results might not be complete.
A user with a dual stack host will perform thorough tests of all target addresses.
Single stack testing:
Previously it was possible to only test IPv4, but not possible to only test IPv6 on a dual stack host. This patch adds such an option.
Other:
IPv6-only networks are relatively common now, for instance many mobile networks use DNS64/NAT64, under this setup the behaviour of only testing IPv4 addresses would fail completely. DNS64 detection may be a desirable addition here, as it would alert users of such configuration. The possibility also exists to force testing the IPv4 addresses via the NAT64 prefix, while testing the IPv6 addresses directly. Without NAT64 awareness, the output could be misleading and incomplete as DNS64 synthesizes IPv6 addresses where none exist.